Monster Media 1994 #2

home *** CD-ROM | disk | FTP | other *** search

/ Monster Media 1994 #2 / Monster Media No. 2 (Monster Media)(1994).ISO / renegade / tcr110b2.zip / TCR.DOC < prev next >

Wrap

Text File | 1994-06-02 | 42KB | 881 lines

| TCR v1.10 Beta 02 Documentation | | Automated Call Return Door | | Copyright 1993,1994 by Tim Strike and Forbidden Knights Systems. | Released on June 2nd, 1994. ____________ INTRODUCTION ____________ This program won't mean a lot to many people; but to those of you have have need of something that calls the user back without doing anything else will find this door very useful. It may also come in handy as a generic callback door for ANY BBS software that can internally or externally process a success file. TCR is based on the Callback Validator type system, except that TCR does absolutely no "validating". The concept of TCR was first established when a few friends were looking for a door that could be setup to do a return call on certain users. In some areas, calls one way are long distance, yet the return call is a local call. Something like this: Point1 ------(LD)------> Point2 <---(Local)------ The idea was to get a door going for the Point2 system, where the Point1 system would start the call, and Point2 would then callback so that no charges (except the initial dialup) are incurred by the Point1 system. So what's the point of the entire thing? Well, imagine that Point2 was a BBS, and Point1 was a slew of callers from one specific area. Normally, Point2 might find the interest in the BBS diluted because callers are unwilling to take the costly plunge. TCR is an attempt at a solution for systems who find themselves in the Point2 situation with callers in the Point1 area unwilling to commit. As an extension to this idea, TCR creates a "success" file. If the BBS program processes this success file as successful validation, TCR can be turned into a generic callback validation system. The only worries of the various programmers/BBS authors is to process this file, and validate the user accordingly. TCR does all the logistical work of calling the user, keeping logs, etc... ___________ BETA STAGES ___________ This program is still in it's beta stages. Since this program has direct interaction with the modem and it's result codes, there are likely to be many problems. In order to iron out as many of these bugs as possible, it was decided that a wide beta version would be distributed. This wide beta version will increase in beta revisions until it is suitable for release. Testing has been continually run with the two modems that I own, but there are bound to be other problems that arise with different sets. TCR may not run prefectly until a standard version is released, and even then, it may not run as smooth as silk. ;) Please report any bugs that you may discover. _________________ PROGRAM OPERATION _________________ TCR requires the DOOR.SYS file to be in the current operating directory. If you are running TCR from a different directory, make sure that somehow the DOOR.SYS file gets copied into the TCR executable directory or specify the command line /D:<path> which will be used to load the DOOR.SYS file from that path. PLEASE NOTE THAT THIS DOOR WILL ONLY WORK AS WELL AS YOU SET IT UP. YOU MUST CHANGE THE .DAT FILES. YOU MUST CHANGE THE MODEM CONFIGURATION. And that's likely not all of it. If you have any problems getting this door to work, please drop me a line. _______ SAMPLES _______ TCR has three data files that is uses to parse/process numbers. TCR-LOCK.DAT is a file that locks out numbers from the callback process. TCR-DIAL.DAT is a file which is used to trim the phone number from the 1-###-###-### format to something that is dialable. The TCR-LONG.DAT file contains a list of all the numbers that you will call back long distance. If you do not put anything in this file, even if you have long distance calls set to YES, they will not be processed. TCR also uses another data file, TCR-CALL.DAT to store which users it has called back, their original numbers, names, the dialed number, password attempts and date/time. This file has a specific format which is listed in the sample file; it will change as users become validated, and their numbers get added to the data file. If you do NOT have these files, then TCR will operate as normal; however you will likely end up dialing numbers you don't want to dial. The samples are in the file called SAMPLES.ZIP, and you should UNZIP that file into your TCR directory and read and change the files. It is very important that these files be setup for YOUR area and YOUR setup, as my sample setup files work for my system only! ____________________ INSTALLATION (BASIC) ____________________ Now, let's get some examples down so we can get TCR installed on your board, and running for your users. |-| PART 1 - Creating Neccessary Files |---------------------------| Copy the TCR.EXE file into a directory you wish to use as your TCR directory (this could be your main BBS directory if you so choose). PKUNZIP the file SAMPLES.ZIP into your TCR directory, and load them into your text editor and change them accordingly (descriptions are listed inside these two files). It is very important that you change these files. Run TCR SETUP to change the defaults and setup your modem information. It is very important that you do this; make sure the init strings you supply will cause the modem to work in VERBOSE description mode. See the section on SETUP for further information on the many variables tha SETUP offers. PKUNZIP the file TEXT.ZIP into the directory you defined in the TCR SETUP screens as your "text" directory. This could be your TCR directory if you have a seperate TCR directory, or perhaps your TEXT directory for your BBS software. |-| PART 2 - BBS Installation |------------------------------------| Next you need to install it into your BBS. Setup your BBS to create the dropfile DOOR.SYS, and then run TCR -- you could also make it run a batch file instead, something like: @ECHO OFF CD\BBS\TCR TCR /D:<path to DOOR.SYS> CD\BBS EXIT Please note that YOU should restrict access to the door through your menus. If you only want people in certain locations to be called back, create a flag for them and control the menu access with that flag. (this example for Telegard/Renegade) Long Description .. : (R)eturn Call - System Calls You Back Short Description . : (R)eturn Call Command letters ... : R ACS ............... : s25fA ^- Can be anything -- I suggest that you restrict ACS to those people that you want to use the door with an AR flag. Keys .............. : DG MStr .............. : TCR.BAT I am only familiar with Telegard and Renegade, and as such I can not provide any further setup examples to cover installations into all BBS packages. If you install TCR into other programs besides Telegard or Renegade, please netmail me with the instructions so that I can add them to future documentation. _______________ "SETUP" COMMAND _______________ The setup option of TCR can be invoked by simply typing "TCR SETUP" on the command line. Once this is done, a screen similar to the following should appear: 1. Text path : C:\TCR\ 2. Log file : C:\TCR\TCR.LOG 3. # Changes : Yes 4. Boot Callers : Yes 5. Attempts : 3 6. Waiting Time : 5 seconds 7. Connect Time : 30 seconds 8. Random Pass : Yes 9. User Pass : Yes 0. Pass Attempts : 3 A. Lock Previous : No B. BBS Name : The Call Return Door L. Long Distance Handling M. Modem Setup Option (1) sets the textfile directory. This is where you unzipped the TEXT.ZIP file which contains the TCR text files. Option (2) sets the logfile that will be kept by TCR of all the activities that occur in the door. Option (3) sets if the user is allowed to input alternate numbers. If this option is set to NO, the only phone numbers available will be those given in the DOOR.SYS file -- if those two numbers are the same, the user will be given one option only. If YES, the number the user inputs will be logged. Option (4) sets the Automated Call Boot. This option will detect NO DIAL TONE and RING strings during the callback. if this option is set to YES, then the phone will be answered, and a message will be sent to the connecting user, then TCR will hangup. This allows the call return procedure to continue as normal. IT IS HIGHLY RECOMMENDED THAT THIS OPTION BE SET TO YES. Option (5) sets the number of callback attempts that should be made. If the user doesn't connect in the specified time, TCR will try again until it has tried this amount. Option (6) sets the waiting time before the call return starts. After the user is disconnected, it will pause until this time limit has been reached, then initialize the modem and start the call return. Option (7) sets the waiting time AFTER the number has been dialed. If no connection is made in this time, the loop will end. This should be set to your S7= setting (at minimum). Option (8) sets if TCR should use a random password to verify that the user being called back is the user that was on before. Option (9) sets if TCR should use the user password to verify that the user being called back is the user that was on before. Option (0) sets the number of times the user can fail the password. If the user fails this number of times, they are hungup. Option (A) sets if TCR should call a number that is has called before. It is suggested that this option be NO, but for some SysOps the option has been installed. If you are going to be using this door in the call return, not the callback verify mode, then this option should definately be set to NO. Option (B) sets the BBS name. This is displayed to the user when calling the user back, or when answering the phone in callboot mode. Option (L) sets the long distance setup. When you hit this option, a screen similar to the following should appear: 1. Allow LD : No 2. Hangup after : Yes Morning Afternoon 1 1 1 1 1 1 2.1.2.3.4.5.6.7.8.9.0.1.2.1.2.3.4.5.6.7.8.9.0.1. A. Sunday : XXXXXXXX··XXX··························XXXXXXXXX B. Monday : XXXXXX····XXX·······························XXXX C. Tuesday : XXXXXX····XXX·······························XXXX D. Wednesday : XXXXXX····XXX·······························XXXX E. Thursday : XXXXXX····XXX·······························XXXX F. Friday : XXXXXX····XXX·······························XXXX G. Saturday : XXXXXXXX··XXX·····························XXXXXX Option (1) sets if the door will allow LD calls. If this option is set to NO, any number beginning with 1- will be denied. Option (2) sets if the door should hangup after the LD call is completed. This option, for those of you who are like me, poor, should be set to YES. However, if your interface requires that the user be online to work, using this option isn't possible (in that case, it is suggested that a menu be created such that the only exit from the menu is to hangup). Options (A) through (G) set the times that LD calls are allowed to be completed. The days Sunday through Saturday have been setup with 48 different time slots (every 30 minutes). If the timeslot has an X in it, then LD calls are allowed during that period. This allows you to setup TCR to only dial LD calls when it is cheapest, etc... Option (M) [back to the main screen now] sets the modem configuration. If you hit this option, a screen similar to the following will be displayed: A. Initialization : ATH0M1L0V1E0Q0X6&C1&D2 B. Dialing : ATDT C. Answering : ATA 1. Connect : CONNECT 2. Busy : BUSY 3. Error : ERROR 4. Okay : OK 5. Ring : RING 6. Voice : VOICE 7. No Carrier : NO CARRIER 8. No Dial Tone : NO DIAL TONE Option (A) sets the modem init string. This should be setup for your modem to have DROP CARRIER ON DROP OF DTR, and VERBOSE result strings. The rest of it you can set according to your modem, but the above two things must be somehow included in the init string. The default should work with most modems -- mine's a USR 16.8 DS and it works great. Option (B) sets the dialing prefix. ATDT for Tone, ATDP for Pulse. Anything beyond that is completely up to you. Option (C) sets the answering string. If Call Boot is on, this will be sent to the modem to answer and boot the caller. Options (1) through (8) set the modem response strings. The only thing of big note is that the CONNECT string should not contain any of the baud rates, but only a keyword in the string that is unique to all the "connect" strings of your modem. The defaults should be fine for most modems. __________ TEXT FILES __________ TCR uses very few prompts in the actual program. Most of the instructions are provided with text files that you can configure. The samples are provided in the file TEXT.ZIP and have everything that you should need to say in them. Only .ASC files have been provided, but TCR will display .ANS files to ANSI callers, and .AVT files to Avatar callers. If you wish to create these files, you can do so at your own discretion. TCR-HEAD .ASC .ANS .AVT File is displayed as a header file before any interaction with the user is started. TCR-HELP .ASC .ANS .AVT File is displayed if user answers YES to the help question. This file could contain some answering information, what's going to happen, etc... TCR-LOCK .ASC .ANS .AVT File is displayed if the users number is listed in the TCR-LOCK.DAT data file. The door will then exit. TCR-HANG .ASC .ANS .AVT File is displayed just before TCR drops the carrier to call them back. Good for short reminders. TCR-OK .ASC .ANS .AVT File is displayed after successful TCR call return (and after passwords have been input correctly). TCR-BAD .ASC .ANS .AVT File is displayed after bad password attempts, just before disconnecting the user. TCR-LONG .ASC .ANS .AVT File will be displayed to long distance (1-) users if LD calling is turned off or if their number fails the LD check. TNC-TIME .ASC .ANS .AVT File will be displayed to long distance (1-) users if current time does not fall within a LD calling window (LD calls must also be allowed). TCR-BUSY .ASC File is displayed if an incoming call is received during a return call session. TCR will answer, display the BUSY file, and then hangup and continue with the return call. _________________________ SETUP: ONE-WAY LD SYSTEMS _________________________ The concept behind this setup for TCR is simple, and for the most part was largely explained during the introduction and initial setup. Once you have the "BASIC" setup installed, you can continue from there. One-way LD systems occur in remote calling areas which have "extended" service because they are in a remote area. These remote areas have been provided with free calling into the main city, but the call going the other way FROM the main city is long distance. This limits the availability of the system to main city callers. The SysOp of such a system can install a return-dialer (TCR) which will call the user back. The call then originates from the remote area, and is free of cost to the user (save the initial dialup charge of perhaps 50 cents). (1) Password checking isn't neccessarily required in this mode. Since the idea is to setup the door for callers who are in the main city, calling them back every day, and having to do double password checks for every logon could become very annoying. It is suggested that both the RANDOM password and USER password checks are turned off. (2) The lock previous option should also be OFF. The door wouldn't work as intended if this option is on, because the user would be able to use the door once, and then never again. Set to NO and leave at NO. ;) (3) The # Changes field is a matter of personal opinion. I personally would choose to put the user's phone number into the USER RECORD, lock it there, and allow no number changes in TCR. This would result in quicker response time of the system dialing the user back. There are obviously other things that will need to be checked. The text files should be changed accordingly, so that mention of validation/password checks, etc are removed depending on how the door has been setup. Change these files before putting the door online. That's more or less it. Since I don't run this type of system (live in the main city) I'm not sure of all the intricacies of this setup. If there are any errors or problems of concern, please feel free to contact me. ____________________ SETUP: CALLBACK DOOR ____________________ The concept behind this setup is a little different. First, it requires more software and a little more work. However, the reason that TCR was made into such a portable system was so that it could easily be moved from BBS to BBS, allowing door authors to quickly interface TCR to the BBS with minimal effort. TCR should first be setup in the "BASIC" setup as described in previous sections of this document. Then, create a batch file that looks like the following: @ECHO OFF CD\BBS\TCR TCR /D:<path to DOOR.SYS> CD\BBS EXIT This is a start to the entire process. When TCR successfully calls the user back, and they successfully input the passwords required, then TCR will create the file SUCCESS.TCR in the current directory. The next step is EXTREMELY important. If, and ONLY if the file SUCCESS.TCR is found, the user should be validated. There are several ways of going about this; (1) The first is to run a script and process this file if it exists. This requires a very versatile script language for the BBS, but there are some powerful BBS script languages out. (2) The second is to get a programmer to create a VALIDATION program, something that will only VALIDATE the user and do nothing else. This is simple in itself; the programmer only need know the record position or user name, etc to find the neccessary files to change. Once this program is written (and there may be some available for your BBS program already), all you need to do is add a line to the bach file: ... CD\BBS\TCR TCR /D:<path to DOOR.SYS> -> IF EXIST SUCCESS.TCR <command> CD\BBS ... The program can then take over, and validate the user. The basic concept is that TCR does all the work with the modem, and this secondary validation program does the validating. You can understand that 15 BBS programs can have 15 "validation" programs, and only need one modem-user interface (TCR). If there is no validation interface for TCR available then you might want to look at programming (or finding someone to program) the interface; since the only thing involved is maniuplating the data files, it makes it an easy job. If someone does program an interface, I'm interested in carrying the interface on my system so that others can download it. Please send/file attach it to me if at all possible. (3) If you can think of any other ways, great! Let me know so that I can include them. Once TCR is interfaced to the BBS program, it'll operate without a problem. If you find that TCR says that the callback session was successful, and the user's record doesn't change, the interface isn't doing it's job -- talk to the author of the interface. If you are looking for interfaces and can't find one for your particular BBS system, please drop me a line. Interfaces for both Telegard and Renegade have been created. The entire development time was about 30 minutes (spread over a few days) and encompasses a little less then 75 lines of code. The process of writing a BBS interface for TCR is extremely easy and uneventful, because all that is required is a few data file checks and updates - nothing that requires any great knowledge of interupts, registers, COM routines, etc - because TCR handles all of that as the "base" program. This setup requires a few changes to the BASIC setup as well: (1) Password checking should DEFINATELY be on for this callback verifier mode. One of the reasons that callback verifications are done are to verify the number AND that the user online is the user called back. This can be done by checking the password. The RANDOM password is an option that I highly recommend. It may annoy a few users who DON'T read the text they are sent, but that becomes their fault, not yours. The RANDOM password is given right before the callback. It's an 8 character ASCII code (A..Z) which will be different for every subsequent call (26^8 total possibilities). This gives a little more security that the callback is going to the correct user. (2) # Changes should be ON. At least I leave it on, because some users put their voice number into the user records, and that's what is contained in the DOOR.SYS, and hence, what TCR would like to call back. Allowing number changes will ensure that the user can be called back at the correct number (and when a number change is done, a 2 line reason field is input and stored in the TCR.LOG file). (3) Callboot should be ON. This is an option, but it's highly recommended for a number of reasons. Incoming calls can have a number of adverse effects on the callback process. If ON, the system will answer the phone, tell the user that a callback is in progress (don't call back for 5 minutes!) and then continue with the original process of dialing the person back. And that's more or less it. The callback verifier/validator option of TCR is more complex, because of the added interface file which is required. However, this provides great flexibility, and it would be nice if interfaces were developed for the popular BBS systems on the market today. ____________________ SETUP: CALL SECURITY ____________________ Want to setup communications that will ALWAYS occur in a specific manner, from a specific destination? TCR can be setup to RETURN the call to a specific phone number. Some might not understand the entire concept behind this, but it's become popular where secure sessions are required (terminal programs such as PcAnywhere provide the service amung others, for those who haven't setup a BBS). Setup using the "BASIC" setup, and then make the following changes: (1) Number changing should be set to OFF. This will ensure that the number that TCR will be forced to callback cannot be changed. (2) Random Password checking should be turned OFF. If the destination number is forced, there is no point for this extra security. Regular password checking should be left ON. (3) Lock Previous should be OFF, such that this call-loop can be done at any given time without being told the process can't be completed because it's been done once (this is a multi-session setup in other words, not a one time thing). Now setup the BBS account to use the number that you wish to dial back. For this user account, the first thing that should occur is a shell to TCR (before getting to the main menu - just force the logon user into the door). NOTE: THIS IS ONLY FOR THE ONE CALLER, OR CALLERS, THAT YOU WISH TO HAVE TCR DO A SECURE DIAL ON. SETUP A SPECIAL SECURITY LEVEL IF NECCESSARY. Now they have no choice but to go through the door, and no choice but to use the number in the user record for the dialback. Now anyone logging on under that account will be called back at a PRE-defined number, which means that account can only be used from that PRE-defined number. ________________________ MULTINODE CONSIDERATIONS ________________________ The largest changes to the 1.10 version of TCR were the multinode considerations made in the program. Multinode callback doors require different options & configurations for different nodes. TCR verisons prior to 1.10 didn't take into consideration these requirements, and anyone installing TCR on a multinode system would have either run into problems or had to kludge their way to making it work. There are only a couple of changes that need to be made when running TCR in a multinode environment. Firstly; the node number should be passed to the batch file TCR.BAT, so that the command line would be something similar to TCR.BAT <node#>. Once this has been done, only a few other changes need to be made. The commandline for TCR must now include /#:%1 (which, translating from the batch command TCR.BAT <node#> would pass the node number to TCR from the batch file). ... CD\BBS\TCR REM TCR /D:<path to DOOR.SYS> -> TCR /#:%1 /D:<path to DOOR.SYS> CD\BBS ... That's the first part that needs to be changed. Any other sections which use the files SUCCESS.TCR and LONGDIST.TCR must also be changed. When the /#:<node#> parameter is included, these files change from SUCCESS.TCR to SUCCESS.<node#> and LONGDIST.TCR to LONGDIST.<node#>. ... CD\BBS\TCR TCR /#:%1 /D:<path to DOOR.SYS> REM IF EXIST SUCCESS.TCR <command> -> IF EXIST SUCCESS.%1 <command> REM IF EXIST LONGDIST.TCR <command> -> IF EXIST LONGDIST.%1 <command> CD\BBS ... Lastly, each modem for each node will require a different setup file. These files are called MODEM.<node#> and are created by the TCR SETUP procedure. To define your various nodes modem configurations, run TCR SETUP /#:<node#> for each of the nodes that you operate on. ________ VERSIONS ________ This section will always contain the history/update information on this program. It will list a general summary of bug fixes and new features. Please read this section on every upgrade, even if you don't plan on reading any other section. +:New Feature *:Updated (Fixed) Feature v1.00 Beta 01 + Written in Turbo Pascal v6.0. + First release to the general public. v1.00 Beta 02 If you are upgrading from Beta 01, delete your TCR.CFG file and run TCR SETUP again to create the larger .CFG file used in Beta 02. There are probably many more changes then this, I just don't remember them all at this point. Things have been hectic around here lately, and work on TCR has been progressing for the last 2 months -- mostly in the last few days -- but I still don't remember all that has been done. ;) + Added password feature (optional) + Added random password feature (optional) + Changed connection detection so that connect ends loop + Added log file + Lockout number now checked after user input + Added long distance callbacks - can be toggled off, or during specified time windows only * Phone number sent to TCR-LOCK.DAT file didn't have the 1- part of the number, so no entries would be locked out properly. + Added TCR-LONG.DAT gives LD numbers that can be called + Added TCR-CALL.DAT which stores previously called systems. If you are using TCR as a call return door (one-way LD systems for instance), then you should leave LOCK PREVIOUS set to OFF. + Various new display files: TCR-BAD Displayed to users who fail password checks TCR-OK Displayed to users after successful call return TCR-LONG Displayed to users who are LD if LD calls are off, or number can't be called (not in TCR-LONG.DAT) TCR-TIME Displayed to users who are LD, and the current time is not during a LD calling time window. v1.00 Beta 03 If you are upgrading from Beta 02 or Beta 02, then you will need to delete your TCR.CFG file, and then run TCR SETUP to create the larger configuration file. I don't remember all of the changes to this version (it's been 4+ months in production, and my notes have since been lost), but I will say this -- it works far better with the modem now then it used to. I added a lot of delays, etc into the code to try and clean it all up and ensure that the modem responses were handled better. TCR also now times itself out if the init doesn't work. The path is also specified now on the command line, which might make it easier for most people to use. The format is TCR <path to DOOR.SYS> - ie, TCR C:\BBS\ would load the DOOR.SYS file in C:\BBS\. Other then that, play a bit and see how it works. v1.10 Beta 01 If you are upgrading from a previous version of TCR, please delete the TCR.CFG file since it is no longer being used (replaced by node dependant modem information files). TCR should now handle multinode setups a LOT better. The new command line /#:<node#> should be included with all multinode setups. This will use a different modem definition file (MODEM.<node#>) instead of the standard MODEM.TCR file, and will use temporary log files so the main log doesn't get corrupted (or filled with entries at different times from different nodes). Including this command will also create multiple success files (SUCCESS.<node#> and LONGDIST.<node#>). PLEASE READ THE SECTION ENTITLED MULTINODE CONSIDERATIONS SINCE IT OUTLINES ALL THE CHANGES THAT ARE NECCESSARY FOR YOU TO COMPLETE. The method to include the DOOR.SYS path has changed to /D:<path> instead of just including the <path> on the command line. Some fossil routine problems have also been fixed up in hopes that some of the weird things (hangs, FAT damages) etc are cleaned up. Some parts of higher memory would inadvertently be wiped out when first running TCR, which wouldn't cause problems when nothing was loaded in this memory, but would if something was. v1.10 Beta 02 Minor changes. /D: directory command was only accepting first 6 characters. Should now work to a length of 65 characters. If number changes were OFF, numbers weren't being written to TCR-CALL.DAT, which was a problem. Fixed. __________ LEGALITIES __________ WARRANTY TCR is provided as-is, without a warranty of any kind, either expressed or implied. It is only guaranteed to occupy disk space, nothing more. Under no circumstances shall the author be liable to you or anyone else for any damages, including (but not limited to) any lost profits, lost savings or other incidental or consequential damages arising out of the use or misuse of this program. In other words; RUN THIS PROGRAM AT YOUR OWN RISK. You yourself, and nobody else is responsible for the outcome of choosing to run this program. COPYRIGHT The program, and all documents and files included in the original TCR release package are copyrighted to Tim Strike and Forbidden Knights Systems. They are not to be modified in any way, shape or form; The distribution archive may be changed from ARJ/ZIP to another archive form, as long as no files are added or removed from the release archive. TCR may be packaged on a distribution diskette or in a compilation archive, but under no circumstances may any charge be incurred beyond the physical cost of the hardware (disks, CD...) or trasfer medium (phone, mail...). CREDITS All brand and product names referenced in this document are trademarks, registered trademarks, or copyrighted works of their respective holders. _____________________ CONTACTING THE AUTHOR _____________________ I can be contacted in a number of different methods. When sending netmail or posting in one of the conferences, direct mail to "Tim Strike". Replies will be forthcoming as soon as I can get to them. NETMAIL: Telenet Canada Fidonet Xnet ITCnet 20:22/101 1:259/423 40:41/108 85:896/521 ECHOMAIL CONFERENCES: TNC_BBS BBS Support (TNC) TNC_FKNIGHTS Forbidden Knights Support (TNC) POSTAL MAIL: Forbidden Knights Systems Attn: Tim Strike 3360 Council Rind Rd, Unit 11 Mississauga, ON L5L 2E4 BULLETIN BOARD: Forbidden Knights Systems (905)820-7273 2400-16,800 Courier Dual Standard Access denied between 4:00am and 5:00am Restricted access between 9:00pm and 10:00pm Any changes or upgrades that need to be made to TCR v1.10 will be made as time permits. Further suggestions, comments and/or bug reports can be directed through one of the above methods. Enjoy fully.